Serve on every shard: one reactor and SO_REUSEPORT listener each - #58

Fixes the root cause behind WS_SHARDS=1 in consumers' fly.toml. The server ran on one thread whatever WS_SHARDS said, and warned at every boot that a nagoya listener couldn't be shared between reactors.

Depends on pathscale/nagoya#16 (0.1.13, bind_shared/SO_REUSEPORT).

• listen_on: with more than one shard, it binds the first listener shared, then starts a ws-shard-N thread for each extra shard. Each thread has its own Reactor::local and its own SO_REUSEPORT listener on the concrete address, so a connection is accepted, registered and served on one reactor and never crosses a thread.
• prepare sets up the server (Arc<Self>) and the connection table once, shared by every shard, so the toolbox reaches a connection whichever shard holds it. serve_shard is the old accept loop.
• The first shard owns the stop (signals or the caller's) and cancels the others through Shutdown. listen returns after all shards have joined.
• One shard: same path as before.
• TcpListener::bind_shared / bind_any_shared. The docs on listen and the accept loop are updated.
• 3.3.0 to 3.3.1, and nagoya's minimum goes to ^0.1.13 because bind_shared requires it.

Tested: new tests/sharded_listen.rs, a WS_SHARDS=3 server over TCP. 12 clients each completed an echo request, served by the first shard and ws-shard-2 (macOS doesn't balance; Linux does), and one stop ended all shards with listen_until returning Ok. Full suite: 151 pass. Clippy is clean with --all-features. Built against the local nagoya branch.

Once both are released, consumers can drop WS_SHARDS from fly.toml.